Ensuring a positive customer experience is important for growth in electronic commerce. As such greater emphasis is being placed on designing electronic commerce systems that are personalized to a customer and easily navigable. Conventional e-commerce sites have created various methods to maximize the customers experience encompassing requiring user registration to specialized system architectures.
Representing the state of user sessions of client-server interactions is a challenging task, and conventional client-server systems represent state using a variety of software architectures. For example, some systems may save session state in a cookie on the client, while other systems may save the state in a data file on the server or utilize server sessions to track state. Yet other systems may communicate state through the networked resources themselves.
One example of the latter approach is the HATEOAS (Hypermedia as the Engine of Application State) REST (Representational State Transfer) style of software architecture. The REST architecture is a style of software architecture utilized by distributed hypermedia systems, such as the World Wide Web (WWW), that attempts to represent application state over a computer network via linked hypermedia. Software systems that comply with the principles of REST architecture are client-server based, stateless, layered, cacheable, optionally utilize on-demand code, and maintain a unified interface between the clients and servers.
HATEOAS is a constraint of the REST architecture that specifies all interaction between client(s) and server(s) is accomplished through hypermedia dynamically provided by the server(s). In principle, interactions utilizing such an approach may not require an intermediary session state (i.e., state may be completely represented in the hypermedia itself). A typical HATEOAS system is composed of discrete resources (objects), each of which has a consistent address (e.g., Uniform Resource Location “URL”) that can be accessed by a requesting client over a computer network, such as the Internet. Each individual resource also has a consistent representation, which is indicated by a MIME (Multipurpose Internet Mail Extensions) type defined via the HTTP ‘Content-Type’ header for the resource. The representations can be encoded and transmitted between the server and client in any suitable format, such as JSON and XML, for example.
Resources of a typical HATEOAS system are inter-related via relationships that are defined exclusively by links embedded in the data object which is a representation of each resource. In other words, as a HATEOS system is “stateless” in principle, the state of the system is contained in the resources themselves and the links between resources. Each link includes a “REL” field defining the name of the relationship to the other resource and a “HREF” field defining the address (e.g., URL) to the other resource. During client-server interactions, a HATEOAS system provides four actions on resources: GET, POST, PUT, and DELETE.
In practice, the REST HATEOAS architectural style has numerous deficiencies, which the present invention has been conceived to address. For example, in the REST HATEOAS architecture, additional information is included within the HTTP header, thus tying a typical HATEOAS system to the HTTP protocol itself. Such a configuration may therefore render the typical system unusable with protocols other than HTTP. To address this deficiency, the embodiments disclosed herein remove the HTTP protocol and provide the semantics in a more neutral manner, thereby allowing for client-server interaction across a variety of protocols, if desired. Nonetheless, the HTTP protocol may be one of the protocols, among others, used to engage a system in accordance with embodiments of the present disclosure.
A second deficiency of the REST HATEOAS architecture arises once the objects are separated from their HTTP receiver endpoint. Specifically, the objects lose the content type and URL identity, and therefore this information must be provided via other mechanism(s). Thus, the disclosed embodiments embed this information in a data structure, referred to as the “self entity,” of the object itself.
A third deficiency of the REST HATEOAS architecture is that the ‘Content-Type’ headers must transmit two distinct pieces of information: the type of the object and the encoding method. In typical systems, these two pieces of information may be concatenated with a “+” symbol within the HTTP header string. However, this practice obfuscates both pieces of information, and potentially makes processing of incoming requests from clients difficult and/or error-prone. Accordingly, the disclosed embodiments move the MIME type of the object into the above-mentioned self entity, and preserve the ‘Content-Type’ HTTP header for the purpose of expressing the object encoding method, such as JSON, XML, etc.
A fourth deficiency of the REST HATEOAS architecture is that a URL of a resource is a poor identifier in a complex, highly scaled web server implementation. For example, once a client accesses the system on one server, all the links in the representations are typically configured to point to the same server instance, thus “sticking” that client to that server instance. Thus, in practice, a scaled deployment utilizing a pool of servers must rely on a single entry point, such as a server load balancer, that routes request(s) from requesting client(s) to a particular server within the pool of servers. The servers in the pool must know the name of this entry point and construct their URLs to point to this entry point explicitly. Furthermore, the object itself is highly inflexible and breakable as its URL points to a hard server entry point. For example, as the pool of available servers decreases as one or more severs become unavailable, URL reference(s) to the unavailable server(s) are lost. As another example, as the pool of available servers increases, the clients that are stuck to particular server instances may not be able to utilize the additional computing resources, thereby leading to unbalanced server loading.
More importantly, by combining the server location and the URI of the resource together to form the URL, a typical system breaks a central REST tenet, namely, statelessness. The disclosed embodiments address these issues by separating the identity of the object from the server that provided the object. This identity, referred to as the URI, is stored in the above-described “self” entity and can be used to address the same logical resource on one or more other server instances.
As a fifth deficiency, the REST HATEOAS architecture has no concept of the user performing operations, and instead assumes completely anonymous interactions. Such a configuration is woefully impractical in most modern systems (e.g., e-commerce systems) where user authorization and/or authentication are required to consume resources and execute transactions. The disclosed embodiments address this issue by introducing the concept of a “resource operation,” (e.g., action to be performed on a resource) and defining an “authorization server” to determine whether a requesting user is authorized to perform a given resource operation. Accordingly, all resource operations must provide a user identifier indicating the identity of the requesting user. The identity of the user may be an anonymous identifier, a user role identifier, or other identifier which does indicate personally identifiable information. Such a configuration may therefore allow the user to access resources that are dedicated exclusively to the user and/or to access resources that are dedicated to a particular “role” shared by the user and one or more other users.
A sixth deficiency of the REST HATEOAS architecture is that it is difficult to develop systems that utilize servers that communicate asynchronously with runtime executable programs on the client, in a REST HATEOAS compliant manner, since much of the information about the resources being downloaded via HTTP is contained in HTTP headers that are not easily accessible to the runtime executable programs.
A seventh deficiency is centered on the ‘State’ part of REST. The State of the system is transferred between the client and the server (the T part of REST), but only at the request of the client. The server has no mechanism to communicate the current state without the client calling for it. This leads to the problem of State Mismatch, where the client's perception of the system state is different from the server. This leaves the client to make incorrect decisions based on old state. It also leaves the client only one choice to mitigate the problem, which is to refresh the state as often as they can.
REST currently follows the Client-Server architecture characterized by the flow of control. The Client initiates a call to the Server, which processes the request. The Server formulates a response and sends it back to the Client. The Client processes the response and then may issue follow-on requests.
A variation on this is the “asynchronous” call-response architecture, where the client initiates a request but does not wait for a response. Instead, the server calls the client back when a response is ready for consumption. The advantage of this model is that the client does not have to block, waiting for the server to respond. A disadvantage is that the client has to keep track of which response belongs to which request.
As an eighth deficiency, the REST HATEOAS electronic commerce platform involves integration of third party business commerce systems with the existing business API. In the REST HATEOAS, the commerce process is generalized into resources, relationships, and workflows. This generalization defines the Business API.
Integration of the electronic commerce platform with third party commerce platforms presents problems of compatibility between each systems API definitions and operations. This compatibility issue requires modification of the API code in order to ensure proper integration of respective platforms. This deficiency can rapidly compound in the event that a commerce platform must be integrated with multiple third party platforms and thus require significant changes to the core electronic commerce platform to integrate and resolve any potential conflict between the electronic commerce platform and each third party commerce platform.
Lastly, the Business API must not only be constructed to be fully integrated with any and all third party commerce platforms, but it also must also clearly project the capabilities and data of the business to the consumer. The process of conveying the business to consumers can be a complex process involving software developers, website planners, and ultimately the business leadership. Accordingly, the potential for additional costs and time to market incurred in the planning, development, and implementation of the commerce platform primarily exist in the communication and interactions between each level of the design and development process.